Subject: DLSw Capabilities Exchange

From: "Allen Carriker ((919)254-4170)" <[email-masked]>
Date: Thu, 23 Sep 93 08:54:19 EDT

Wayne,

  Please include our positions in your latest capabilities summary.
  They are listed below.

thanks,

Allen Carriker
IBM Network Routing Systems
[email-masked]
(919)254-4170

_________________________________________________________
Subject: DLSw Capabilities Exchange
From: "Allen Carriker ((919)254-4170)" <[email-masked]>
Date: Fri, 10 Sep 93 12:15:45 EDT
Message-Id: <[email-masked]>

Hello, my name is Allen Carriker.

This append outlines our initial input on the capabilities
issues raised to date.

1. BASE/OPTIONS:  Currently, we feel that the base for DLSw should
                  consist of:

                  - RFC 1434 (less NetBIOS support)
                  - Capabilities Exchange (This must contain an
                    indication of the SAP values supported)
                  - MIB

2. Vendor Id/Release Number in capabilities:  We would like to
        strive for interoperability.  We propose that a block of
        optional capability vector ids be issued to each vendor
        and that a vendor could use a vector after contributing
        the function to the DLSw architecture.  This would
        facilitate vendor creativity and freedom while maintaining
        interoperabilty.

        We also support a DLSw version number.

3. TCP vs. UDP for capabilities:  Use another SSP message flow on
        the existing DLSw circuit.

4. Capabilities Format:  GDS (key length)

5. CUR/ICR as an option:  We do not see the need for this option, but
     we would like to see a definition for this and also an explanation
     of its benefit.

6a. How should DLSw capable routers find out about each other.
6b. Directory/Name server function.

   As far as these items are concerned, we feel that a broader and
   more encompassing approach to the following three tasks is required.

          i) learning DLSw partners (reduces sysdef, etc...)
         ii) learning network entities (reduces broadcast, etc..)
        iii) learning circuit path (reduces possible loops, etc...)

    The learning of DLSw partners, target network entities, and in
    addition, DLSw circuit paths, can all be improved through either
    DLSw-to-DLSw or DLSw-to-server flows.  We should focus on finding
    the best choice for each of these tasks taking into consideration
    the outcome of other SIGlets.

    i. How should DLSw capable routers find out about each other:

         We would like to see a server on the WAN (with a well-known
         address) that maintains a database of DLSw capable routers
         and their associated WAN subnet (IP) addresses.  This would
         require the addition of a new protocol between the server and
         the DLSw capable routers.

   ii. How should DLSw learn the location of a network entity:

         Each DLSw capable router will probably maintain a cache of
         network entities (i.e., names for NetBIOS nodes and MAC
         addresses for SNA nodes) that can be reached on the local
         links.  In some cases, this information could be sysdefed
         for server type nodes (e.g., 3745).  Mechanisms need to
         exist for exchange of this information with other DLSw
         capable routers.

 iii. How should the DLSw learn the path through the WAN subnet.

         This topic is primarily being addressed by the loop
         prevention SIGlet.  Within this SIGlet, we have made some
         proposals concerning the use of region identifiers (associated
         with each bridged LAN) and transport network identifiers
         (associated with each WAN subnet) that could be used to support
         the protocol mechanisms for (6a) and (6b). These parameters
         would be carried in a DLSw Hello PDU (i.e., heartbeat)
         that is multicast on each LAN to other DLSw capable routers.

Allen Carriker
IBM Network Routing Systems
[email-masked]
(919)254-4170